1. Field of the Invention
The present invention relates to the field of service oriented computing and, more particularly, to a technique for defining and dynamically enabling service level requirements in a service oriented architecture (SOA).
2. Description of the Related Art
As enterprise information systems expand in both geography and capability, many businesses have implemented a service oriented architecture (SOA) to provide a consistent and re-usable interface for connecting requesting clients with any business process or information provider. The increase in popularity of SOA has resulted in the creation of a large number of software and middleware components that can be used in implementation. While some SOA solutions require specific software and middleware components, others can support a variety of components and protocols. Further, additional software components exist that can be added to the SOA to provide supplementary functions for governance.
The current implementation of SOA has created an environment that impedes the implementation of service level requirements. Service level requirements are the generic language terms that define the implementation and performance criteria for a specific service, such as provide a real-time update. A service processing environment is typically used to provide a programming interface for a specific middleware component. A disconnect arises between the language used to document service level requirements and the language used by the service processing environment to define like items. That is, a one-to-one correlation does not exist to translate the generic natural language terms of the service level requirement into the terms used by the service processing environment. Therefore, implementing service requirements in a SOA requires in-depth knowledge of the service implementation and infrastructure capabilities of the service processing environment. Even with this in-depth knowledge, an implementer often uses subjective interpretations of the natural language used to define the service level requirements. Code maintainers or SOA architects may re-interpret these loosely specified requirements in the future, which can result in a SOA service malfunctioning.
Because such a detailed level of knowledge is required, enabling service level requirements within a SOA environment incurs a high level of cost. Typically, available SOA knowledgeable personnel are limited. Despite this limitation, SOA knowledgeable personnel are required to design and modify SOA applications and to design and modify SOA infrastructure components. SOA knowledgeable personnel are presently diverted to coordinate with management personnel on requirement modification issues and/or interpretations. Similarly, coordination with these same knowledgeable people is needed to determine an effect of deploying new SOA services and an effect of changing the SOA infrastructure upon existing SOA services and their associated requirements.
What is needed is a means to enable service level requirements within a SOA that does not require in-depth knowledge of service implementation and infrastructure capabilities. Ideally, such a means would utilize a formalized language for defining service level requirements that can be translated into the language used by the service processing environment by an interpreter program at runtime. Therefore, service level requirements would be consistently defined, which also provides a single location for applying modifications, and dynamically applied to each received service request.